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ABSTRACT 


The  performance  of  network  management  tools  for  SONET/SDH  networks  sub¬ 
ject  to  the  load  conditions  is  studied  and  discussed  in  this  thesis.  Specifically,  a  SONET 
network  which  consists  of  four  CISCO  ONS  15454s,  managed  by  a  CISCO  Transport 
Manager,  is  set  up  in  the  Advanced  Network  Laboratory  of  the  Naval  Postgraduate 
School.  To  simulate  a  realistic  data  transfer  environment  for  the  analysis,  Smartbits  Ava¬ 
lanche  software  is  deployed  to  simulate  multiple  client-server  scenarios  in  the  SONET 
network.  Traffic  from  the  management  channel  is  then  captured  using  a  packet  sniffer. 
Queuing  analysis  on  the  captured  data  is  performed  with  particular  emphasis  on  proper¬ 
ties  of  self- similarity,  hi  particular,  the  Hurst  parameter  which  determines  the  captured 
traffic’s  degree  of  self- similarity  is  estimated  using  the  Variance-Index  plot  technique. 
Link  utilization  is  also  derived  from  the  computation  of  first-order  statistics  of  the  cap¬ 
tured  traffic  distribution.  The  study  shows  that  less  management  data  was  exchanged 
when  the  SONET  network  was  fully  loaded.  In  addition,  it  is  recommended  that  CTM 
4.6  be  used  to  manage  not  more  than  1552  NEs  for  safe  operation.  The  results  presented 
in  this  thesis  will  aid  network  planners  to  optimize  the  management  of  their  SONET/SDH 
networks. 
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EXECUTIVE  SUMMARY 


The  growth  in  Internet  has  led  to  an  unprecedented  shift  in  traffic  behavior,  pat¬ 
tern  and  content.  This  trend  has  inadvertently  resulted  in  a  surge  in  the  demand  of  band¬ 
width  for  the  consumer  market.  Similarly,  there  is  also  an  anticipated  increase  in  the 
bandwidth  for  military  operations  and  deployments.  With  the  paradigm  shift  from  plat¬ 
form-centric  warfare  to  network-centric  warfare  to  leverage  information  superiority,  it  is 
crucial  to  put  in  place  a  fully  automated  and  reliable  network  for  the  warfighters. 

The  Synchronous  Optical  Network  (SONET)  standard  in  North  America  and  the 
Synchronous  Digital  Hierarchy  (SDH)  standard  -  the  international  equivalent  of  SONET 
-  are  seen  as  enabling  technologies  to  fulfill  the  worldwide  growing  bandwidth  demand 
in  the  commercial  market.  As  more  and  more  optical  networks  are  deployed  to  meet  this 
bandwidth  demand,  more  sophisticated  management  tools  are  required  to  ensure  proper 
optimization  of  network  resources  and  end-to-end  reliability.  Unfortunately,  the  band¬ 
width  allocated  for  management  of  these  next  generation  optical  networks  is  constrained. 

In  this  study,  the  effect  of  traffic  loading  on  the  performance  of  Element  Man¬ 
agement  System  (EMS)  that  is  used  for  managing  SONET/SDH  networks  is  investigated. 
The  results  obtained  will  aid  in  understanding  how  well  the  management  system  will 
scale  when  operating  in  conjunction  with  a  heavy  traffic  load. 

For  the  purpose  of  this  study,  a  SONET  network  was  set  up  in  the  Advanced  Net¬ 
work  Laboratory  at  the  Naval  Postgraduate  School.  The  network  management  tool  de¬ 
ployed  was  the  Cisco  Transport  Manager  (CTM)  version  4.6.  In  addition,  Spirent’s  Ava¬ 
lanche  Smartbits,  a  traffic  generator,  was  installed  and  configured  to  generate  user  traffic 
on  the  SONET  ring.  Data  was  then  passively  captured  from  the  CTM  4.6  server  via 
Ethereal,  a  packet  sniffer.  Note  that  only  Socks,  SNMPv2  and  TCP  traffic  from  CTM  4.6 
were  relevant  for  the  detailed  analysis. 

The  results  gathered  from  Ethereal  were  compared  to  the  findings  obtained  in  Ref. 
[5].  Preliminary  observation  showed  that  less  traffic  was  exchanged  between  the  CTM 
and  the  managed  NEs  when  the  SONET  network  is  loaded.  Close  inspection  revealed 
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that  more  Socks  and  SNMP  traffic  were  transferred  when  there  is  no  user  traffic  on  the 
network. 

Further  analysis  on  the  inter-arrival  time  and  packet  size  distribution  were  per¬ 
formed.  From  the  inter-arrival  distribution,  all  the  traffic  (Socks,  SNMPv2  and  Ethernet 
traffic)  demonstrated  long  range  dependence  and  self- similarity,  regardless  of  the  load 
conditions  in  the  SONET  network.  However,  it  was  observed  that  management  data  was 
exchanged  at  a  shorter  time  interval  without  user  traffic  in  the  SONET  network.  For  the 
packet  size  distribution,  it  was  found  that  the  packet  size  of  all  traffic  were  very  similar 
under  different  load  conditions. 

The  Hurst  parameter  (H)  was  then  used  to  estimate  the  self- similarity  of  all  the 
traffic.  Using  the  Variance-Index  Plot  approach,  large  values  of  H  were  found  for  all 
traffic,  thus  indicating  that  the  traffic  is  self-similar  and  bursty  in  nature.  These  results 
were  similar  to  Ref.  [5]  except  for  Socks  and  combined  Socks  and  SNMP  traffic. 

The  link  utilization  was  derived  for  all  the  traffic  collected.  In  particular,  CTM 
4.6’s  Socks  and  SNMP  traffic  had  a  link  utilization  of  0.612  when  CTM  4.6  is  used  to 
manage  2500  network  elements  (NEs).  This  value  was  much  lower  compared  to  the  high 
utilization  of  0.926  obtained  in  Ref.  [5]  under  no-load  condition  in  the  SONET  network. 
Though  the  utilization  was  lower  in  the  case  of  having  user  traffic  in  the  network,  the 
high  Hurst  parameter  value  computed  may  pose  a  problem  for  the  CTM  4.6  to  manage 
the  2500  NEs. 

A  network  utilization  versus  queue  depth  graph  was  plotted  to  determine  the 
number  of  NEs  that  the  CTM  is  capable  of  managing,  taking  into  account  the  burstiness 
of  the  traffic.  From  the  plot,  it  is  recommended  that  the  CTM  4.6  manages  up  to  a  maxi¬ 
mum  of  1552  NEs,  operating  within  a  utilization  of  0.38  under  load  conditions  in  the 
SONET  network  to  prevent  queuing  buffer  overflow  (compared  to  1027  NEs  under  the 
no-load  condition  in  the  SONET  network). 
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I.  INTRODUCTION 


A.  MOTIVATION 

The  world  is  publishing  and,  in  turn,  consuming  the  large  quantities  of  data  on  the 
Internet.  According  to  the  August  2004  bandwidth  report,  US  broadband  penetration 
broke  50%  in  July  2004  [1].  Indeed,  the  growth  in  Internet  has  led  to  an  unprecedented 
shift  in  traffic  behavior,  pattern  and  content.  This  trend  has  inadvertently  resulted  in  a 
surge  in  the  demand  of  bandwidth  for  the  consumer  market. 

Similarly,  there  is  also  an  anticipated  increase  in  the  bandwidth  for  military  opera¬ 
tions  and  deployments.  With  the  paradigm  shift  from  platform-centric  warfare  to  net¬ 
work-centric  warfare  to  leverage  information  superiority,  it  is  crucial  to  put  in  place  a 
fully  automated  and  reliable  network  for  the  warfighters  [2], 

The  Synchronous  Optical  Network  (SONET)  standard  in  America  and  the  Syn¬ 
chronous  Digital  Hierarchy  (SDH)  standard  -  the  international  equivalent  of  SONET  - 
are  seen  as  enabling  technologies  to  fulfill  the  growing  bandwidth  demand.  Currently, 
SONET/SDH  is  capable  of  supporting  a  line  rate  of  up  to  40  gigabits-per- second  (Gbps) 
at  OC-768  [3],  As  more  and  more  optical  networks  are  deployed  to  meet  the  bandwidth 
demand,  more  sophisticated  management  tools  are  required  to  ensure  proper  optimization 
of  network  resources  and  end-to-end  reliability.  Unfortunately,  the  bandwidth  allocated 
for  management  of  these  next  generation  optical  networks  is  constrained.  It  is  not  well- 
understood  how  well  these  management  systems  will  scale  when  operating  in  conjunction 
with  a  heavy  traffic  load.  It  will  therefore  be  worthwhile  to  analyze  the  nature  of  traffic 
produced  by  management  tools  and  their  ability  to  manage  large  networks  under  fully 
loaded  conditions. 

B.  THESIS  OBJECTIVE 

The  primary  objective  of  this  thesis  was  to  study  and  analyze  the  effect  of  traffic 
loading  on  the  performance  of  Element  Management  System  (EMS)  that  is  used  for  man¬ 
aging  SONET/SDH  networks.  A  SONET  network  with  traffic  generated  using  the  Ava¬ 
lanche  Smartbits  from  Spirent  Communications  [4]  was  simulated  under  laboratory  con- 
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ditions  with  a  commercial  EMS  running.  Based  on  the  network  load  captured  from  the 
EMS,  a  statistical  analysis  was  then  performed.  As  a  follow-up  to  the  thesis  by  Wee 
Siong  Lim  [5],  the  focus  of  this  thesis  was  to  compare  and  model  the  statistical  nature  of 
network  traffic  generated  by  the  Cisco  Transport  Manager  (CTM)  version  4.6  for  self¬ 
similarity  with  and  without  traffic  in  the  SONET  ring.  The  number  of  optimum  number 
of  Network  Elements  (NEs)  was  also  determined  based  on  the  derived  results. 

C.  RELATED  WORK 

There  is  significant  research  in  the  general  area  of  network  management.  Much 
of  the  contemporary  research  is  not  focusing  on  the  management  of  the  network  and  pro¬ 
tocols  employed  for  the  network  management.  Rather,  the  research  today  involves  study¬ 
ing  the  performance  of  network  management  as  more  functions  are  embedded  into  the  in¬ 
telligent  network  elements  [6,  7],  In  addition,  the  industries  are  also  looking  into  the  de¬ 
velopment  of  network  management  across  multiple  service  providers  and  across  multiple 
technologies  (e.g.  Marconi  [8],  Telcordia  [9]). 

Within  the  Naval  Postgraduate  School  (NPS),  one  of  the  research  focuses  for  the 
Advanced  Networking  Laboratory  has  been  in  the  arena  of  network  management,  in  par¬ 
ticular  on  SDH/SONET  networks.  Recent  work  by  Kok  Seng  Lim  [10],  which  studied 
the  effect  of  SNMP  traffic  on  Network  Management  Systems  (NMS),  showed  that  a 
NMS  can  effectively  manage  a  network  with  less  than  200  NEs.  Additional  laboratory 
research  by  Wee  Shoong  Lim  [5]  recommended  using  the  CTM  for  managing  up  to  1027 
NEs  in  SDH/SONET  network  operating  within  a  link  utilization  of  38%  that  can  be  sup¬ 
ported  by  a  reasonably- sized  queuing  buffer.  Lim’s  analysis  was  performed  without  any 
user  traffic  transiting  the  managed  switches.  Consequently,  it  did  not  consider  manage¬ 
ment  traffic  in  a  realistic,  operational  environment.  Although  SONET/SDH  management 
traffic  is  exchanged  in  an  out-of-band  channel  from  user  traffic  and  thus  has  no  direct 
impact  on  user  metrics,  it  is  useful  to  examine  whether  a  fully  loaded  network  will  cause 
the  transiting  switches  to  generate  management  messages  at  a  different  time  interval  and 
of  different  length  than  when  no  user  traffic  at  all  is  being  passed  on  the  network. 
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D.  SUMMARY 

The  organization  of  the  thesis  is  as  follows:  Chapter  II  discusses  the  SONET  net¬ 
work  management  tool  and  SNMP  protocol  used  with  a  focus  on  the  Cisco  Transport 
Manager  4.6  (CTM  4.6).  Chapter  III  describes  the  procedures  for  setting  up  the  labora¬ 
tory  SONET  network,  the  Avalanche  Smartbits,  the  EMS,  and  the  capturing  of  the  net¬ 
work  load  used  in  this  study.  Chapter  IV  briefly  reviews  queuing  theory  and  the  concept 
of  self-similarity.  Chapter  V  presents  the  traffic  analysis  done  on  the  captured  traffic  and 
discusses  the  results  obtained.  Chapter  VI  concludes  the  study  and  provides  suggestions 
on  further  research  areas. 
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II.  SONET  NETWORK  MANAGEMENT  TOOL 


A.  CHAPTER  OVERVIEW 

This  chapter  gives  an  overview  on  the  network  management  protocols  with  a  fo¬ 
cus  on  the  Simple  Network  Management  Protocol  (SNMP)  used  in  our  CISCO  equip¬ 
ment.  The  chapter  then  continues  to  provide  readers  an  insight  on  CISCO  Transport 
Manager  (CTM)  Release  4.6  tool  used  in  the  laboratory  set-up. 


B.  INTRODUCTION 

Early  SONET  vendors  adopted  the  standard  transaction  language  1  (TL1)  inter¬ 
face  from  Bellcore  (now  Telcordia)  to  perform  operation,  administration,  maintenance 
and  provisioning  (OAM&P)  [3],  The  drawback  for  TL1  is  that  it  requires  a  man  in  the 
loop  to  gather  relevant  information  and  perform  routine  diagnostic  checks.  With  the  in¬ 
creased  complexity  in  the  SONET  network,  the  need  for  automation  in  network  manage¬ 
ment  becomes  essential.  Many  vendors  including  the  six  main  SONET/SDH  equipment 
manufacturers:  Alcatel  Network  Systems  (Alcatel),  Fujitsu  Network  Transmission  Sys¬ 
tems  (Fujitsu),  Lucent  Technologies  (Lucent),  NEC  Transmission  (NEC),  Nortel  Net¬ 
works,  and  Tellabs,  instead  build  their  own  software  to  manage  their  SONET  equipment 
and  nodes  [5].  In  addition  to  these  vendor- specific  protocols,  the  International  Standardi¬ 
zation  for  Organization  (ISO),  International  Telecommunications  Union  -  Telecommuni¬ 
cations  (ITU-T)  and  Internet  Engineering  Task  Force  (IETF)  also  developed  separate 
open  standard  network  management  protocols. 

C.  SNMP 

SNMP  was  first  developed  in  1988  by  the  IETF  to  manage  nodes  in  the  IP  net¬ 
work  and  has  since  become  the  de  facto  standard  for  internetwork  management.  As  the 
name  implies,  it  is  a  simple  solution  with  minimal  code  for  implementation.  In  addition, 
its  extensibility  allows  vendors  to  easily  build  additional  management  functions  to  then- 
existing  products.  SNMP  also  separates  the  management  architecture  from  the  architec- 


5 


ture  of  the  hardware  devices,  which  broadens  the  base  of  multi-vendor  support  [11],  The 
latest  version  of  SNMP  is  SNMPv3. 

Common  to  both  SNMP  Version  1  and  SNMPv2  is  a  set  of  management  com¬ 
mands  and  responses  (get,  getNext,  set  and  trap).  Figure  1  summarizes  the  details  of  each 
command  in  SNMPv2.  Illustrated  in  the  figure,  the  get,  getNext,  getBulk  and  set  com¬ 
mands  are  issued  by  the  management  system  to  retrieve  single  or  multiple  object  vari¬ 
ables.  The  managed  agent  responds  to  complete  the  commands.  To  identify  an  occur¬ 
rence  of  an  event,  a  trap  command  is  used.  Of  significance  to  SNMPv2,  compared  to  its 
previous  version,  is  its  improved  security  features  and  its  ability  to  handle  a  huge  volume 
of  management  data  via  the  getBulk  command  [12]. 


D.  CTM  4.6 

CTM  4.6  is  the  element  management  system  (EMS)  for  the  CISCO  Optical  Net¬ 
work  System  (ONS)  15000  series  product  line  [13].  For  the  purpose  of  our  study,  the 
CISCO  ONS  15454,  with  the  capability  for  supporting  high  speed  optical  and  gigabit 
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networking,  was  used.  Via  SNMPv2,  CTM  4.6  collects  its  network  information  from 
CISCO  Transport  Controller  (CTC),  an  EMS  shipped  with  the  ONS  15454. 


As  the  most  advanced  optical  EMS  for  Cisco  ONS  15000  series  products,  CTM 
4.6  can  scale  up  to  2500  NEs  and  100  concurrent  clients.  It  provides  a  variety  of  graphi¬ 
cal  user  interfaces  (GUI)  namely  the  domain  explorer,  network  map,  NE  explorer  and 
alarm  browser.  Figures  2  to  5  show  examples  of  screenshots  of  each  GUI.  The  domain 
explorer,  Figure  2,  provides  a  logical  view  of  the  network  plus  alarm,  connectivity,  and 
operational  status.  Administrators  use  the  domain  explorer  to  create  groups  of  NEs  and 
to  organize  the  domain  in  a  hierarchy.  The  network  map,  Figure  3,  displays  the  geo¬ 
graphical  layout  of  the  network.  Node  position,  node  icons  and  background  map  images 
can  be  customized  in  this  view.  The  NE  explorer  window,  Figure  4,  presents  equipment¬ 
provisioning  information  about  the  selected  NE.  Based  on  the  user’s  selection  of  the  NE, 
this  configuration  information  is  retrieved  through  CORBA,  SNMP  or  TL1.  The  alarm 
browser  display,  Figure  5,  presents  alarms  and  conditions  in  the  managed  domain.  Each 
alarm  is  categorized  into  various  levels  of  severity  (e.g.  critical,  major,  minor  or  warn¬ 
ing).  In  addition  to  the  GUI  and  management  functions,  CTM  4.6  also  supports  an  ex¬ 
tensive  collection  of  performance  statistics  across  the  network  for  export  or  display. 


Cisco  Transport  Manager  -  Domain  Explorer  -  Administrator 
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Figure  2.  Screenshot  of  domain  explorer  (From  Ref.  [14].) 
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Figure  3.  Screenshot  of  network  map  (From  Ref.  [14].) 
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Figure  4.  Screenshot  of  NE  explorer  (From  Ref.  [14].) 
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Figure  5.  Screenshot  of  alarm  browser  (From  Ref.  [14].) 


E.  SUMMARY 

The  SNMP  protocol  was  discussed  in  this  chapter  and  the  differences  between 
SNMP  and  SNMPv2  were  highlighted.  An  overview  of  CTM  4.6  was  also  provided  to 
give  insight  to  the  product  used  in  the  set-up. 

The  next  chapter  describes  the  SONET  network  and  Avalanche  configuration  in 
the  laboratory  and  the  procedures  which  were  performed  to  capture  the  data  for  analysis. 
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III.  LABORATORY  SET-UP  AND  PROCEDURES 


A.  CHAPTER  OVERVIEW 

This  chapter  describes  the  SONET  network  and  equipment  configuration  in  the 
laboratory  which  includes  the  installation  steps  and  challenges  faced  during  the  set-up. 
Next,  the  chapter  will  discuss  the  procedures  performed  to  collect  data  for  analysis. 


B.  LABORATORY  SET-UP 

Figure  6  shows  the  logical  implementation  of  the  SONET  network  and  Avalanche 
Smartbits  in  the  Advanced  Networking  Laboratory. 


Figure  6.  Logical  implementation  of  the  Advanced  Network  Laboratory’s  SONET  net¬ 
work  with  simulated  traffic  loading 
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As  seen  from  Figure  6,  the  SONET  network  is  formed  by  four  ONS  15454s  con¬ 
nected  in  a  ring.  Each  ONS  is  connected  to  the  Avalanche  Smartbits  via  the  multi¬ 
layered  ethernet  card  ML- 1000.  In  addition,  one  of  the  ONS  15454  is  connected  to  an  IP 
network  which  acts  as  a  bridge  between  the  IP  and  SONET  networks. 


C.  EQUIPMENT  CONFIGURATION 
1.  Installing  ONS  15454s 

The  four  ONS  15454s  in  Advanced  Networking  Laboratory  were  installed  by 
Lieutenant  Mathew  Klobukowski.  These  four  ONS  were  connected  in  the  ring  to  form 
the  SONET  network  and  configured  to  simulate  a  regional  network.  Each  ONS  was  as¬ 
signed  a  NE  Identification  (ID)  and  IP  address  as  shown  in  Table  1.  Link  tests  were  con¬ 
ducted  and  it  was  found  that  one  of  the  links  between  the  ONS  15454s  was  down.  Recon¬ 
figuration  on  that  particular  link  was  then  performed. 


NE  ID 

IP  Address 

Caimel 

192.168.200.210 

Pacific  Grove 

192.168.200.211 

Monterey 

192.168.200.212 

Salinas 

192.168.200.213 

Table  1.  NE  ID  and  IP  address  assignment 


2.  Installing  the  ML-1000 

The  ML-1000,  a  gigabit  Ethernet  card,  was  installed  in  each  ONS15454  to  provi¬ 
sion  the  Ethernet  interface  for  Avalanche  Smartbits.  The  ML-1000  card  was  configured 
via  the  console  port.  In  this  case,  an  adaptor  is  required  to  connect  to  the  console  port  as 
an  RJ-1 1  interface  is  used  instead  of  the  typical  RJ-45  interface.  Upon  connection,  a  “no 
shutdown”  command  was  issued  at  the  command  prompt  of  the  CISCO  IOS  such  that  the 
interfaces  available  are  no  longer  “administratively  down”. 

Next,  the  link  aggregation  for  the  ML-1000  card  (both  gigabit  Ethernet  and 
Packet-over-SONET  (POS)  channels)  was  configured.  IP  addresses  were  assigned  to 
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the  gigabit  Ethernet  and  POS  interfaces  as  shown  in  Table  2.  Table  3  illustrates  an  ex¬ 
ample  of  the  configuration  of  the  ML- 1000.  After  the  configuration  was  completed,  a 
“show  interface”  command  allowed  the  status  of  the  interface  to  be  monitored  as  shown 
in  Figure  7.  hi  addition,  ping  commands  were  executed  to  ensure  that  the  links  between 
the  gigabit-ethernet  and  the  POS  interface  across  ONS  15454s  were  configured  correctly. 


Host  Name 

IP  Address 

gigabitethemet  0 

POSO 

POS1 

Carmel 

192.168.120.183/24 

192.168.1.183/24 

192.168.2.183/24 

Monterey 

192.168.100.183/24 

192.168.1.163/24 

192.168.2.163/24 

Pacific  Grove 

192.168.110.183/24 

192.168.1.173/24 

192.168.2.173/24 

Salinas 

192.168.90.183/24 

192.168.1.153/24 

192.168.2.153/24 

Tab! 

e  2.  IP  addresses  for  interface  of  each  ML- 1000 

ML- 1000  Configuration _ 

hostname  Monterey 

! 

interface  gigabitethemet  0 
ip  address  192.18.110.163  255.255.255.0 
no  shutdown 
! 

interface  gigabitethemet  1 
no  ip  address 

i 

interface  POS  0 

ip  address  192.168.1.163  255.255.255.0 
crc  32 

i 

interface  POS  1 

ip  address  192.168.2.163  255.255.255.0 
crc  32 

i 

ip  route  0.0.0.0  0.0.0.0  posO 

| 


T able  3 .  Configuration  of  ML- 1 000 
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Router#  show  int  gigabitethernet  0 

GigabitethernetO  is  up,  line  protocol  is  up 

Hardware  is  FEChannel,  address  is  0005 . 9a39 . 6634  (bia  0000.0000.0000) 

MTU  1500  bytes,  BW  200000  Kbit,  DLY  100  usee, 

reliability  255/255,  txload  1/255,  rxload  1/255 

Encapsulation  ARPA,  loopback  not  set 

Keepalive  set  (10  sec) 

Unknown  duplex,  Unknown  Speed 

ARP  type:  ARPA,  ARP  Timeout  04:00:00 

No.  of  active  members  in  this  channel:  2 

Member  0  :  FastEthernet 0  ,  Full-duplex,  Auto  Speed 

Member  1  :  FastEthernetl  ,  Full-duplex,  Auto  Speed 

Last  input  00:00:01,  output  00:00:23,  output  hang  never 

Last  clearing  of  "show  interface"  counters  never 

Input  queue:  0/150/0/0  (size/max/drops/flushes);  Total  output  drops:  0 
Queueing  strategy:  fifo 
Output  queue  :0/80  (size/max) 

5  minute  input  rate  0  bits/sec,  0  packets/sec 
5  minute  output  rate  0  bits/sec,  0  packets/sec 
820  packets  input,  59968  bytes 

Received  0  broadcasts,  0  runts,  0  giants,  0  throttles 
0  input  errors,  0  CRC,  0  frame,  0  overrun,  0  ignored 
0  watchdog,  0  multicast 

0  input  packets  with  dribble  condition  detected 
32  packets  output,  11264  bytes,  0  underruns 
0  output  errors,  0  collisions,  0  interface  resets 
0  babbles,  0  late  collision,  0  deferred 
0  lost  carrier,  0  no  carrier 

0  output  buffer  failures,  0  output  buffers  swapped  out. 


Figure  7.  Screenshot  of  status  monitoring  of  an  interface 


3.  Installing  CTM  4.6 

Mr.  Wee  Shoong  Lim  set  up  the  CTM  4.6  server,  Oracle  8i,  CTM  database 
schema  and  CTM  web  server  on  the  Sun  Solaris  8  Operating  System  (OS)  in  the  Ad¬ 
vanced  Network  Laboratory.  In  addition,  SNMPv2  was  also  enabled  on  ONS 15454  as  it 
is  the  underlying  protocol  for  CTM  4.6  as  shown  in  Figure  8.  As  indicated  on  Figure  8, 
SNMPv2  was  configured  to  use  the  community  name  “AdvNetLab”  and  the  UDP  port 
162  for  sending  SNMPv2  traps  to  the  CTM  4.6  server  (IP  address  -  192.168.200.10).  The 
“Maximum  Trap  per  Second”  was  also  set  to  0  such  that  all  traps  are  sent  to  the  CTM  4.6 
server. 


Next  the  CTM  4.6  client  was  installed  onto  a  PC  running  Windows  XP.  The  NEs 
to  be  monitored  by  the  CTM  4.6  server  were  added  through  the  CTM  4.6  client  and  the 
performance  monitoring  option  in  the  CTM  4.6  was  enabled.  Finally,  to  verify  that  the 
CTM  server  was  running,  a  “showetm”  command  was  executed.  Processes  like 
“CTMServer”,  “SNMPTrapService”  and  “SMService”  as  shown  in  Figure  9  indicate  that 
the  server  is  up  and  running. 
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Figure  8.  ONS15454s’  SNMPv2  configuration  (From  Ref.  [5].) 


W i n d ow  Edit  Options 


Terminal 


.Jj 

Help 


tt  showctrn 

CTM  Processes  for  Transport Manager  Server  version  4.6.0.520 


root  569  0.0  0.411672  7304  ?  S  Jul  17  0:00  /opt/Ci scoTransportManagerServer/bi n/CTMServer 

root  590  0.0  0.92260016568  ?  S  Jul  17  7:50  /opt/Ci scoTransportManagerServer/bi n/CTMServer 

root  689  0.3  4.920676096360  ?  S  Jul  17  SnmpTrapServi ce 

root  609  0.0  6.0218400118744  ?  S  Jul  17  SMService 

root  18281  0.0  16.2378880322280  ?  S  Jul  19  0NS1 5454/0NS1 5327/0NS1 5600  NEService-21 

root  18565  0.0  7.7218512152876  ?  S  Jul  19  0NS1 5454/0HS1 5327  PMService-2 

root  581  0.0  0.2  5536  3400  ?  S  Jul  17  Apache  Web  Server 

»  I 


Figure  9.  CTM  processes  running  on  the  server  (From  Ref.  [5].) 
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4.  Installing  Avalanche  Smartbits 

In  this  study,  the  Avalanche  SmartBits,  a  performance  analysis  test  platform  de¬ 
veloped  by  Spirent  Technology,  was  chosen  to  emulate  traffic  on  the  SONET  ring.  Fig¬ 
ure  10  illustrates  the  various  levels  one  can  choose  from  for  configuring  the  Avalanche 
system  to  meet  their  testing  requirements.  The  Avalanche  system  allows  easy  emulation 
of  client-server  environments.  Various  test  files  can  be  loaded  for  simulations.  Some  of 
the  test  specifications  that  can  be  configured  through  the  GUI  include  load  constraints, 
random  error  generation  and  network  profiles  (e.g.,  TCP  retries  and  routing).  For  device 
testing,  various  interfaces  can  be  specified.  Subnet  addressing  can  also  be  specified  for 
simulating  large  network  infrastructures.  In  addition,  the  Avalanche  system  allows 
simulating  different  user  characteristics  through  user  profiles.  Each  user  profile  is  then 
correlated  with  a  set  of  associated  test  files  to  simulate  many  simultaneous  users  in  the 
Avalanche  environment  [15]. 


Figure  10.  Avalanche  system  emulation  (After  Ref.  [15].) 

Figure  1 1  shows  the  set-up  of  the  Avalanche  Smartbits  hardware  in  the  labora¬ 
tory.  The  chassis,  which  housed  the  TeraMetrics  gigabit  Ethernet  interface  cards,  was 
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connected  to  the  network  via  the  Ethernet  port  found  on  the  chassis  backplane.  In  this 
case,  an  IP  address  of  192.168.200.150  was  assigned  to  the  chassis  via  the  console  port. 


SUT 


Figure  11.  Set-up  of  Avalanche  hardware  (From  Ref.  [9].) 


The  Avalanche  software  was  then  installed.  Using  the  Smartbits  chassis  admini¬ 
stration  window  each  TeraMetrics  module  was  configured.  Figure  12  shows  the  configu¬ 
ration  set-up  in  the  Smartbits  chassis  administration  window 


Add  Chassis  |  Delete  Chassis  |  |  ' 

/iew  Chassis  Info  |  View  Rpm  List  | 

Chassis  List 

Cards 

F?  99  LAN-3321  ACO. 25:  AB 

1 —  P7  MS)  LAN-3321  AfO.3'): AB 

Card  Name  |  Serial  #  |  IP  Address  |  Gateway  |  Subnet  Mask  j  DNS  |  Ssl  Accel 

LAN-3321  ACO  ,25:  AB  1m33901S2  |l  92.1 68.200 .153  |l  92.168200.1  1255.255.255.0  jo.0.0.0  [Off 

LAN-3321  ACO, 35:  AB  M33901S1  |l  92.1 68.200.1 54  |l  92.1 68.200.1  255.255,255.0  |0.0.0.0  |Off 

_il _ 1-tJ 

F-.-rti 

Port  Name 

MAC  Address 

speed 

Media 

Duplex 

Auto  Negotiation 

LAN-3321  ACO  ,2,05:  AB 

0-0-0-0-0-1 1 

1  Gig 

Fiber 

Full 

Disable 

LAN-3321  A(0 ,2,1  ):AB 

0-0-0-0-0-1 2 

1  Gig 

Fiber 

Full 

Disable 

LAN-3321  ACO  ,3.0):  AB 

0-0-0-0-0-1 9 

1  Gig 

Fiber 

Full 

Disable 

LAN-3321  ACO  ,3,1  ):AB 

0-0-0-0-0-1  a 

1  Gig 

Fiber 

Full 

Disable 

Test  Cancel  Ok 

Figure  12.  Configuration  set-up  in  the  Smartbits  chassis  administration  window 
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Next,  client-server  scenarios  were  defined  in  the  Avalanche  software  to  simulate 
the  traffic  loading  in  the  SONET  network  as  shown  in  Figure  13.  As  seen  in  the  figure, 
Carmel  and  Salinas  were  configured  to  be  connected  to  a  hundred  clients  each.  HTTP 
servers  were  configured  to  be  connected  to  Pacific  Grove  and  Monterey. 


Figure  14  shows  the  screenshot  of  the  GUI  to  define  the  clients’  IP  addresses.  A 
similar  GUI  is  used  to  define  the  IP  addresses  of  the  server.  Traffic  was  then  generated 
by  the  Web  connections  from  clients  to  the  HTTP  servers.  Figure  15  shows  the  set-up  of 
the  client  actions  to  access  the  HTTP  server  in  the  user  profile. 
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Figure  14.  Screenshot  of  the  GUI  to  define  the  clients’  IP  addresses 


Figure  15.  Screenshot  of  a  client  profile  to  access  the  HTTP  server 
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D.  DATA  COLLECTION 

Ethereal,  an  open  source  packet  sniffer  program,  was  used  to  capture  the  desired 
data  for  analysis.  As  seen  in  Figure  1,  Ethereal  was  installed  in  the  same  machine  as  the 
CTM  4.6  Server  to  passively  capture  incoming  and  outgoing  traffic  from  the  CTM.  The 
traffic  includes  management  data  of  all  network  elements  and  SNMPv2  traps  sent  to  the 
Server.  In  this  study,  the  CTM  Server  was  left  running  for  a  period  of  10  days  to  gener¬ 
ate  sufficient  data  for  analysis.  Figure  16  shows  a  screenshot  of  the  data  captured  using 
Ethereal. 


Figure  16.  Screenshot  of  data  captured  using  Ethereal 


E.  SUMMARY 

The  configuration  of  the  SONET  network  and  the  equipment  used  were  presented 
in  this  chapter.  The  data  collection  process  was  also  described. 

The  next  chapter  provides  readers  with  some  background  on  the  queuing  theoiy 

and  self-similarity  concepts  used  for  the  analysis  of  the  data. 
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IV.  QUEUING  THEORY  AND  SELF-SIMILARITY  CONCEPT 


A.  CHAPTER  OVERVIEW 

This  chapter  provides  a  brief  review  of  discrete  random  variables.  In  addition, 
the  queuing  equations  used  in  this  specific  study  are  highlighted.  Lastly,  the  self¬ 
similarity  concept,  in  particular  the  Hurst  parameter  is  presented. 

B.  DISCRETE  RANDOM  VARIABLES 

Equations  (4.1)  to  (4.4)  define  important  characteristics  of  discrete  random  vari¬ 


ables  [16]: 

Mean:  E[X]  =  fix=Y,k  Pr|*  =  (4.1) 

allk 

Second  Moment:  E[ X2]  =  ^k2  Pr[x  =  k ]  (4.2) 

allk 

Variance:  Var  [X~\  =  E[(X  -  nx)2]  =  E[X2~\  — n2x  (4.3) 

Standard  Deviation:  <jx  =  JVax\X\.  (4.4) 


Using  the  results  of  Equations  (4.1)  and  (4.4),  the  coefficient  of  variation,  an  im¬ 
portant  parameter  for  queuing  analysis,  is  derived  as  shown  in  Equation  (4.5).  This  coef¬ 
ficient  gives  a  normalized  measure  of  variability  [16]. 

Coefficient  of  Variation:  (4.5) 

E'x 

Two  important  distributions  related  to  queuing  theory  will  be  discussed  in  the 
next  subsection. 


1.  Exponential  Distribution 

The  exponential  distribution  has  the  following  distribution  and  density  functions 


F{x)  =  \-eXx 


(4.6) 


21 


f(x)  =  Xe-x\ 


(4.7) 


Figure  17  and  18  plot  the  exponential  probability  density  and  probability  distribu¬ 
tion,  respectively. 


EjiponentLa  I  PD  F 


X 


Figure  17.  Exponential  probability  density  (From  Ref.  [17].) 


Eji  pc  ne-ntla  I  CDF 


X 


Figure  18.  Exponential  probability  distribution  (From  Ref.  [17].) 


Note  that  the  mean  of  the  distribution  is  equal  to  its  standard  deviation: 

E{X]  =  crs=j. 


(4.8) 
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This  distribution  is  important  in  queuing  theory  because  we  can  assume  that  the  service 
time  of  a  network  is  exponential  [16]. 

2.  Poisson  Distribution 

Another  important  distribution  for  queuing  analysis  is  the  Poisson  distribution.  It 
is  used  to  model  the  number  of  events  occurring  within  a  given  time  interval  [17],  It  is 
given  by: 

Pi[X  =  k]  =  j^e~*  (4.9) 

where  X  is  the  shape  parameter  which  indicates  the  average  number  of  events  in  a  given 
time  interval.  Figure  19  plots  the  Poisson  distribution  with  4  different  X  values. 


Figure  19.  Poisson  distribution  for  X  =  5,  15,  25  and  35  (From  Ref.  [17].) 

The  poisson  distribution  can  be  applied  to  arrival  rate  and  are  expressed  as: 

(XT)k  _XT 

Pr[  k  items  arrive  in  the  time  interval  T ]  = - e 

k\ 

^[number  of  items  to  arrive  in  time  interval  T]  =  XT 
Mean  arrival  rate,  in  items  per  second  =  X . 


(4.10) 

(4.11) 

(4.12) 
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Assuming  that  the  inter-arrival  time  is  exponentially  distributed,  we  can  relate  to 
the  Poisson  process  as  shown  in  the  equations  below: 

Pr[ Inter-arrival  time  <  t]  =  1  -  (4. 13) 

E[  Inter- arrival  time]  = — .  (4. 14) 

X 

From  Equation  (4.14),  the  mean  inter-arrival  time  is  the  reciprocal  of  the  arrival  rate  [16], 


C.  QUEUING  EQUATIONS 

For  analysis  in  the  subsequent  chapter,  the  equations  in  [16]  are  highlighted  as 
shown  below.  From  (4.14), 

X  = - - - .  (4.15) 

Mean  inter-arrival  time 

The  service  time,  Ts,  is  the  packet  transmission  time  of  a  packet  switched  system 
[16].  Therefore,  Ts  is  given  by 

Mean  packet  size  (bytes)  x  8  . .  . 

L  = - - - .  (4.16) 

Link  Speed 

Thus,  the  link  utilization  p  is  derived  as  shown  below: 

p  =  XTs.  (4.17) 

D.  SELF-SIMILARITY  CONCEPT 

Exponential  and  Poisson  distributions  are  commonly  used  in  queuing  analysis. 
However,  “Poisson-like”  models  suggest  that  traffic  is  smooth  with  predictable  bursts 
[18].  This  assumption  is  usually  not  valid  for  most  data  traffic.  A  number  of  studies 
demonstrate  that  the  traffic  patterns  of  data  are  more  self- similar  than  Poisson  [16],  [19], 
[20].  Self-similarity  provides  a  more  accurate  traffic  analysis  and  takes  into  account  the 
burstiness  of  traffic.  In  this  section,  an  overview  of  the  Hurst  parameter  and  queue  depth 
will  be  discussed. 

1.  Hurst  Self-similarity  Parameter 

The  Hurst  parameter,  H,  is  a  measure  of  self- similarity.  A  traffic  is  said  to  be 

self-similar  if  the  value  of  H  is  high,  i.e.,  H  »  1.0.  There  are  many  approaches  to  esti- 
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mate  H.  In  this  study,  the  variance-time  plot  is  used  to  analyze  the  data  captured.  Using 
this  approach,  H  is  estimated  by  analyzing  the  variances  of  aggregated  processes,  (V”), 
where  m  is  an  integer  representing  the  number  of  samples  considered  in  a  given  sample 
window  [5].  From  [16],  the  variance  obeys  the  following  for  large  m: 

Var(x(m))  ~  Vay  (4.18) 

nr 

where  /?  is  defined  as: 

H=  1-09/2).  (4.19) 

Taking  the  logarithm  on  both  sides  of  Equation  (4.18), 

log[Var(x(m))]  ~  log[  Var(A')|-  p\og(m)  (4.20) 

A  variance-time  plot  is  obtained  by  plotting  log[Var(x"')]  vs  log(m).  ft  is  obtained 
from  the  gradient  of  the  plot.  H  is  then  calculated  using  Equation  (4. 19). 


2.  Queue  Depth  for  Self-similar  Traffic 

Self-similar  traffic  is  characterized  to  be  bursty  in  nature  [16].  In  a  network  sce¬ 
nario,  this  burstiness  in  the  traffic  causes  network  buffer  to  overflow,  if  not  properly  allo¬ 
cated.  Thus,  in  this  study,  the  queue  depth  or  the  buffer  requirement  is  calculated.  The 
queue  depth  of  a  network,  q,  is  defined  as  a  function  of  the  mean  utilization,  p  and  H  as 
shown  in  the  equation  below  [21]: 


(4.21) 


Note  that  Equation  (4.21)  is  valid  for  networks  with  fixed  length  packets.  In  this  study,  it 
is  reasonable  to  use  this  equation  as  an  approximation  since  the  SNMP  and  the  Socks 
packet  lengths  have  fairly  low  variance. 
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E.  SUMMARY 

This  chapter  briefly  reviewed  the  characteristics  of  random  variable  and,  specifi¬ 
cally,  the  exponential  and  Poisson  distributions.  The  queuing  equations  used  in  the 
analysis  of  this  thesis  were  defined.  The  self- similarity  concept,  in  particular  the  Hurst 
parameter,  was  introduced.  The  queue  depth  and  link  utilization  were  also  discussed. 

The  next  chapter  presents  a  detailed  statistical  traffic  analysis  on  the  data  cap¬ 
tured. 
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V.  TRAFFIC  ANALYSIS  AND  FINDINGS 


A.  CHAPTER  OVERVIEW 

This  chapter  presents  the  observations  and  analysis  from  the  data  captured  under 
load  conditions.  The  first  section  covers  the  observations  from  initial  traffic  analysis  us¬ 
ing  Ethereal.  This  is  followed  by  a  more  detailed  analysis  using  statistical  tools  discussed 
in  Chapter  IV.  The  results  from  the  analysis  are  then  compared  to  the  results  obtained 
under  no-load  conditions  in  [5], 


B.  OBSERVATIONS 

Web  traffic  was  loaded  in  the  SONET  network  throughout  the  entire  data  captur¬ 
ing  process.  The  data  exchange  between  the  CTM  4.6  Server  and  the  managed  NEs  was 
captured  from  December  29,  2004  to  January  7,  2005  over  a  period  of  255  hours.  Table  4 
summarizes  the  traffic  captured.  The  types  of  traffic  that  are  of  interest  to  our  analysis 
are  the  Socks,  TCP  and  SNMPv2  traffic.  Other  traffic  collected  from  the  process  in¬ 
cludes  Address  Resolution  Protocol  (ARP),  User  Datagram  Protocol  (UDP)  and  Domain 
Name  Server  (DNS)  packets  which  are  not  relevant  to  our  study.  In  addition,  the  table 


also  shows  the  data  statistics  from  [5]  for  comparison  and  will  be  discussed  later. 


Type  of  Traffic  Number 
of  Packets 

Without  Load  in 
the  SONET  Net¬ 
work 

With  Load  in  the  SONET  Network 

July  20  — July  30 
2004 

(From  Ref.  [51.) 

December  29,  2004 
-January  7,  2005 

January  11  - 
January  21, 

2005 

Socks  communications 
between  CTM  and  the 
managed  NEs 

203,278 

94,916 

126,008 

TCP  overhead  for  CTM’s 
Socks  communications 

260,461 

107,446 

130,884 

SNMPv2  traffic 

7,364 

4,332 

5,301 

Other  communications  on 
the  network 

193,333 

98,138 

121,180 

Total  packets  captured  on 
the  network 

664,436 

304,832 

383,373 

Table  4.  Summary  oi 

:  traffic  captured  on  CTM  4.6  Server  with  and  without  load  in 

the  SONET  network 
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From  Ethereal,  it  was  observed  that  the  CTM  4.6  uses  CISCO’S  proprietary  Socks 
protocol  to  communicate  with  the  NEs.  From  the  deciphered  payload  section  of  Ethereal, 
General  Inter- ORB  Protocol  (GIOP)  was  determined  to  be  implemented  as  part  of  the 
Socks  protocol.  Ethereal  also  showed  that  CTM  4.6  uses  getbulk  operation  in  SNMPv2 
to  collect  a  large  amount  of  information  from  the  NEs.  SNMPv2  “trap”  packets  sent  by 
the  NEs  were  also  observed.  In  addition,  TCP  traffic  which  includes  the  overhead  for 
setting  up  and  tearing  down  TCP  connections,  TCP  acknowledgements  and  retransmis¬ 
sion  were  observed.  Note  that  these  TCP  traffic  will  be  collectively  termed  as  Ethernet 
traffic.  Thus  far,  all  these  observations  coincide  with  the  findings  in  an  earlier  thesis  [5] 
by  Wee  Shoong  Lim. 

From  Table  4,  it  is  interesting  to  note  that  the  total  amount  of  data  collected  over 
the  almost  similar  period  of  time  under  loaded  conditions  is  approximately  half  that  col¬ 
lected  under  no-load  condition.  To  confirm  this  observation,  another  run  was  performed 
between  January  1 1  and  January  21,  2005,  for  the  same  period  of  time.  During  this  run, 
the  simulated  web  traffic  on  the  SONET  ring  was  interrupted  and  halted  for  2  days.  The 
results  obtained  were  tabulated  in  Table  4.  Comparing  the  two  results,  more  traffic  was 
captured  on  the  second  run.  Close  inspection  of  the  data  captured  revealed  that  the  ex¬ 
change  of  SNMP  and  Socks  traffic  between  CTM  and  the  managed  NEs  account  for  the 
increase  in  the  overall  traffic.  Therefore,  based  on  the  preliminary  assessment,  the  results 
suggest  that  less  management  information  will  be  exchanged  when  the  SONET  network 
is  fully  loaded.  This  is  possible  since  it  may  not  be  necessary  for  each  network  element 
to  update  its  heartbeat  to  the  CTM  when  it  is  not  idling.  This  is  typical  for  protocols  sup¬ 
porting  large  networks  to  ensure  efficiency  and  performance. 

C.  STATISTICAL  ANALYSIS 

The  inter-arrival  time  between  packets  and  packet  size  are  important  parameters 
for  understanding  and  modeling  each  type  of  traffic.  The  inter-arrival  time  between 
packets  is  calculated  by  the  difference  in  arrival  time  between  adjacent  packets  (“Time” 
column  in  Figure  16).  The  packet  size  can  be  extracted  directly  from  the  data  captured 
(“Length”  column  as  shown  in  Figure  16).  In  this  study,  an  unpublished  MathCad  pro- 
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gram  written  by  Lieutenant  James  Young  was  used  to  calculate  these  values  and  generate 
data  samples  to  obtain  the  distribution  plots.  Note  that  the  analysis  in  this  section  is 
based  on  the  data  captured  between  December  29,  2004  and  January  7,  2005.  The  second 
run  only  served  to  confirm  the  observation  of  less  packets  being  captured  under  load  con¬ 
ditions  as  compared  to  the  scenario  without  traffic  traversing  in  the  SONET  ring.  More¬ 
over,  the  data  from  the  second  run  is  incomplete  given  the  2-day  interruption  to  be  able  to 
establish  an  accurate  analysis  on  the  effect  of  traffic  load  in  the  SONET  ring  on  the  net¬ 
work  management  tool. 


1.  Inter-arrival  Time  Distribution 

The  inter-arrival  distributions  for  each  type  of  traffic  are  plotted  in  Figures  20  to 
23. 


Inter-arrival  Time  Distribution  for  Socks  Traffic 


Figure  20.  Inter-arrival  time  distribution  for  Socks  traffic 
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Inter-arrival  Time  Distribution  for  SNMP  Traffic 


Figure  21.  Inter-arrival  time  distribution  for  SNMP  traffic 


Inter-arrival  Time  Distribution  for  Socks  and  SNMP  Traffic 


Time  (seconds) 


Figure  22.  Inter-arrival  time  distribution  for  Socks  and  SNMP  traffic 
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Inter-arrival  Time  Distribution  for  Ethernet  Traffic 


Figure  23.  Inter-arrival  time  distribution  for  Ethernet  traffic 


Figures  20,  22  and  23  demonstrate  a  heavy-tailed  distribution,  thus  inferring  long- 
range  dependence  and  self- similarity  in  the  traffic  [22],  In  addition,  the  majority  of  the 
packets  arrive  within  a  relatively  short  inter-arrival  time  (~  1  second).  For  Figure  21,  the 
distribution  for  SNMP  traffic  resembles  that  of  the  exponential  distribution  with  a  linear 
decay  rate,  X  <  1.  It  is  also  seen  that  SNMP  traffic  has  a  longer  inter- arrival  time  than  the 
other  traffic. 

Using  Equations  (4.1)  to  (4.5),  the  mean,  variance,  and  coefficient  of  variation  of 
the  inter-arrival  time  distributions  were  computed  using  MathCad  and  tabulated  in  Table 
5.  From  Table  5,  it  is  observed  that  all  the  coefficients  of  variation  are  greater  than  1  and 
thus  confirms  our  earlier  deduction  of  a  heavy-tail  distribution.  Table  6  shows  the  results 
obtained  under  the  no-load  condition  (extracted  from  [5]).  Comparing  the  results  from 
Table  5  and  6,  it  can  be  seen  that  all  of  the  traffic,  regardless  of  the  load  conditions,  have 
high  coefficients  of  variation,  implying  a  uniformly  consistent  strong  tail. 
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Type  of  Traffic 

Mean  (s) 

Variance  (s2) 

Coefficient  of 
Variation 

Socks 

8.2 

1.633  x  103 

4.927 

SNMP 

179.533 

4.536  x  106 

11.863 

Socks  &  SNMP 

7.842 

1.563  x  103 

5.041 

Ethernet 

3.213 

542.584 

7.249 

Table  5.  Tabulated  statistics  for  inter-arrival  time  distribution  under  load  conditions 


Type  of  Traffic 

Mean  (s) 

Variance  (s2) 

Coefficient  of 
Variation 

Socks 

4.553 

772.087 

6.103 

SNMP 

120.043 

627080.020 

6.597 

Socks  &  SNMP 

4.394 

745.556 

6.215 

Ethernet 

1.965 

323.759 

9.159 

Table  6.  Tabulated  statistics  for  inter-arrival  time  distribution  under  a  no-load  con¬ 
dition  (After  Ref.  [5].) 


By  substituting  the  mean  values  found  in  Table  5  into  Equation  (4.15),  the  arrival 
rate,  X,  for  the  inter-arrival  distribution  was  computed.  The  calculated  values  are  com¬ 
piled  in  Table  7.  The  values  of  X  for  the  no-load  condition  (extracted  from  [5])  are  also 
included  in  Table  7.  Comparing  the  results,  it  can  be  seen  that  all  the  traffic  tends  to  ar¬ 
rive  at  a  faster  rate  under  the  no-load  condition.  Thus  the  X  value  again  suggests  that 
there  is  less  data  exchanged  between  the  CTM  and  the  managed  NEs  when  the  SONET 
network  is  loaded  with  traffic. 
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Type  of  traffic 

X  (s'1) 

With  Load 

Without  Load  (From 

Ref.  [5].) 

Socks 

0.122 

0.220 

SNMP 

0.00557 

0.008 

Socks  &  SNMP 

0.128 

0.228 

Ethernet 

0.311 

0.509 

Table  7.  Tabulated  value  of  arrival  rate,  X,  for  the  inter-arrival  distribution  with  and 

without  load  conditions 

2.  Packet  Length  Distribution 

The  packet  length  distributions  of  each  type  of  traffic  are  plotted  in  Figure  24  to 
27. 


Packet  Size  Distribution  for  Socks  Traffic 


Packet  size  (bytes) 


Figure  24.  Packet  size  distribution  for  Socks  traffic 
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Packet  Size  Distribution  for  SNMP  Traffic 


Figure  25.  Packet  size  distribution  for  SNMP  traffic 


Packet  Size  Distribution  for  SNMP  and  Socks  Traffic 
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Figure  26.  Packet  size  distribution  for  Socks  and  SNMP  traffic 
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Packet  Size  Distribution  for  Ethernet  Traffic 


Figure  27.  Packet  size  distribution  for  Ethernet  traffic 


Figures  24,  26  and  27  show  a  slight  resemblance  to  exponential  distribution  with  a 
significant  tail.  In  addition,  it  is  observed  that  almost  70%  of  the  Socks  packets  are  less 
than  100  bytes,  i.e.,  the  majority  of  the  packets  are  small  in  size.  On  the  other  hand,  it  is 
seen  from  Figure  25  that  the  packet  size  of  SNMP  is  generally  larger  than  the  Socks 


packet  size  (>  150  bytes).  Using  Equations  (4.1)  to  (4.5),  the  mean,  variance,  and  coeffi¬ 
cient  of  variation  of  the  packet  size  distributions  are  computed  using  MathCad  as  shown 
in  Table  8. 


Type  of  Traffic 

Mean  (bytes) 

Variance  (bytes2) 

Coefficient  of  Variation 

Socks 

171.864 

3.581  x  104 

1.101 

SNMP 

441.173 

6.124  x  104 

0.561 

Socks  &  SNMP 

183.623 

3.995  x  104 

1.089 

Ethernet 

125.262 

2.794  x  104 

1.334 

Table  8.  Tabulated  statistics  for  packet  size  distribution 
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Next,  the  service  time  Ts  was  calculated  by  substituting  the  mean  values  in  Table 
8  into  Equation  (4.16)  and  is  tabulated  in  Table  9.  The  type  of  link  and  speed  for  each 
type  of  traffic  is  also  recorded  in  Table  9.  Table  9  also  presents  the  Ts  values  obtained 
under  no-load  conditions  (extracted  from  [5]).  Comparing  both  results,  it  can  be  seen  that 
the  service  time  under  load  and  no-load  conditions  are  almost  similar. 


Type  of  Traffic 

Type  of  Link  /  Speed 

Ts  under  Load 
Conditions 

Ts  under  No-Load  Condi¬ 
tion  (From  Ref.  [5]) 

Socks 

SDCC  /  192kbps 

7.161  ms 

6.044  ms 

SNMP 

SDCC/  192kbps 

18.382  ms 

18.967  ms 

Socks  &  SNMP 

SDCC  /  192kbps 

7.651  ms 

6.496  ms 

Ethernet 

Ethernet  /  100Mbps 

10.021  ps 

8.214  ps 

Table  9.  Ta 

bulated  values  of  service  time,  Ts,  for  the  packet  size  distributions  under 

load  and  no-load  conditions 


3.  Link  Utilization 

The  link  utilization  was  computed  by  substituting  the  values  in  Table  7  and  9  into 
Equation  (4.17).  The  link  utilizations  for  four  NEs  under  load  conditions  are  calculated 
and  tabulated  in  Table  10.  The  link  utilization  under  the  no-load  condition  is  also  in¬ 
cluded  in  Table  10  (extracted  from  [5]). 


Type  of  Traffic 

Type  of  Link  /  Speed 

Link  Utilization 
under  Load 
Conditions 

Link  Utilization  under 
No-Load  Condition 
(From  Ref.  [5].) 

Socks 

SDCC /192kbps 

8.736  x  10-4 

1.33  x  10-3 

SNMP 

SDCC /192kbps 

1.024  x  10'4 

1.58  x  10'4 

Socks  &  SNMP 

SDCC /192kbps 

9.793  x  10'4 

1.48  x  10-3 

Ethernet 

Ethernet  /  100Mbps 

3.117  x  10'6 

4.18  x  10'6 

Table  10. 

tabulated  link  utilization  for  4  NEs  under  load  and  no-load  conditions 
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Next,  extrapolation  of  the  results  obtained  in  Table  10  was  performed  to  derive 
the  link  utilization  for  2500  NEs  (the  maximum  capacity  of  CTM  4.6).  The  results  are 
tabulated  in  Table  1 1 .  The  link  utilization  under  the  no-load  condition  (extracted  from 
Ref.  [5])  is  also  presented  in  Table  1 1  for  comparison.  From  Table  11,  it  is  observed  that 
the  CTM  4.6,  which  has  both  Socks  and  SNMP  on  SDCC,  utilizes  about  61%  of  the 
SDCC  capacity  when  managing  2500  NEs  under  load  conditions.  This  provides  a  spare 
capacity  of  39%  on  the  SDCC,  compared  to  only  18%  under  the  no-load  condition.  It  is 
interesting  to  note  that  the  preliminary  results  show  the  network  management  protocol 
employed  by  CTM  4.6  is  able  to  handle  2500  NEs  efficiently  even  under  load  conditions. 
More  detailed  analysis  using  the  queue  depth  [22]  will  be  required  to  determine  if  the 
CTM  4.6  is  capable  of  managing  this  large  number  of  NEs  by  taking  into  account  the 
burstiness  of  the  traffic.  In  addition,  from  Table  10,  it  is  observed  that  the  link  utilization 
of  Ethernet  traffic  is  insignificant  as  found  in  [5]. 


Type  of  Traffic 

Type  of  Link  /  Speed 

Link  Utilization 
under  Load  Con¬ 
ditions 

Link  Utilization 
under  No-load 
Condition  (From 
Ref.  [51) 

Socks 

SDCC  /  192kbps 

0.546 

0.830 

SNMP 

SDCC  /  192kbps 

0.064 

0.099 

Socks  &  SNMP 

SDCC /192kbps 

0.612 

0.926 

Ethernet 

Ethernet  /  100Mbps 

1.948  x  10~3 

2.62  x  10'3 

Table  1 1 .  Tabulated  link  utilization  for  2500  NEs  under  load  and  no-load  conditions 


4.  Estimation  of  Self-Similarity 

Figures  28  to  31  show  the  variance  inter-arrival  plots  for  different  types  of  traffic. 
The  variance  packet  size  plots  for  different  types  of  traffic  are  shown  in  Figures  32  to  35. 
Note  the  value  of  log(m)  =  0,  1,  1.5,  2,  2.5  and  3  correspond  to  the  values  of  m  =  1, 10, 
32,  100,  320  used  in  Mathcad  to  generate  data  points  for  the  variance-index  plots.  A  lin- 
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ear  trendline  indicated  in  red  is  added  in  each  plot.  The  function  of  this  straight  line  cor¬ 
responds  to  Equation  (4.20).  It  is,  however,  interesting  to  note  that  the  best-fit  trendline 
for  Figures  28  and  30  is  a  second-order  polynomial.  Thus,  we  can  conclude  that  the 
Socks  and  combined  Socks  and  SNMP  traffic  are  highly  self-similar  in  large  time-scale 
and  less  self-similar  in  smaller  time-scale. 


Variance  Inter-arrival  Time  Plot  for  Socks  Traffic 
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Figure  28.  Variance  inter-arrival  time  plot  for  Socks  traffic 
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Figure  29.  Variance  inter-arrival  time  plot  for  SNMP  traffic 


Variance  Inter-arrival  Time  Plot  for  Socks  and  SNMP  Traffic 


Aggregated  Inter-arrival  Time  Series  Index,  log(m) 


Figure  30.  Variance  inter- arrival  time  plot  for  Socks  and  SNMP  traffic 
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Figure  31.  Variance  inter-arrival  time  plot  for  Ethernet  traffic 


Variance  Packet  Size  Plot  for  Socks  Traffic 


Packet  Size  Series  Index,  log(m) 


Figure  32.  Variance  packet  size  plot  for  Socks  traffic 
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Figure  34.  Variance  packet  size  plot  for  Socks  and  SNMP  traffic 
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Figure  35.  Variance  packet  size  plot  for  Ethernet  traffic 


Using  Equation  (4.20),  the  value  of  /?  can  be  obtained  from  the  gradient  of  the 
line.  The  values  of  H  are  then  computed  by  substituting  /?  into  Equation  (4.19).  Table  12 
tabulates  the  values  of  /?  and  the  corresponding  values  of  H  under  the  load  and  no-load 
conditions  (results  for  no-load  conditions  are  extracted  from  [5]).  From  Table  12,  it  can 
be  seen  that  all  the  traffic  (Socks,  SNMP  and  Ethernet)  under  load  conditions  have  large 
value  of  H  (H  >  0.5),  and  thus  have  a  high  degree  of  self-similarity.  These  high  values  of 
H  also  indicate  that  Socks,  SNMP  and  Ethernet  traffic  are  bursty  [22],  These  results  co¬ 
incide  with  our  earlier  results  obtained  in  the  distributions  plots.  Comparing  with  the  re¬ 
sults  obtained  under  no-load  conditions,  it  can  be  seen  that  most  of  the  traffic  except  for 
Socks  and,  combined  Socks  and  SNMP  traffic  exhibits  similar  characteristics  (i.e.,  highly 
self- similar  and  bursty). 
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Type  of  Traffic 

Under  Load  Conditions 

Under  No-Load  Condition 
(From  Ref.  [5].) 

P 

H 

WM 

H 

Socks  Traffic  (Inter-arrival 
time) 

0.3855 

0.8073 

0.99 

0.505 

Socks  Traffic  (Packet  size) 

0.3489 

0.8256 

0.8867 

0.5567 

SNMP  (Inter-arrival  time) 

0.3372 

0.8314 

0.5952 

0.7024 

SNMP  Traffic  (Packet  size) 

0.5301 

0.7349 

0.1869 

0.9066 

Socks  &  SNMP(Inter- 
arrival  time) 

0.3752 

0.8124 

0.9785 

0.5108 

Socks  &  SNMP(Packet  size) 

0.3504 

0.8248 

0.7547 

0.6227 

Ethernet  (Inter-arrival  time) 

0.5332 

0.7334 

0.6324 

0.6838 

Ethernet  (Packet  size) 

0.3141 

0.8430 

0.395 

0.8025 

Table  12.  Tabulated  value  of  /?  and  H  under  load 

.  and  no-load  conditions 

5.  Effects  of  Self-Similarity  on  Queue  Depth 

Figures  36  to  38  plot  the  mean  utilization  of  the  network,  p,  versus  the  queue 
depth,  q,  in  Equation  (4.21)  using  the  values  of  H  in  Table  12.  Different  scales  for  q  are 
applied  to  each  plot.  As  can  be  seen  in  the  figures,  the  queue  buffer  requirements  begin 
to  increase  drastically  at  lower  levels  of  utilization  for  higher  values  of  H  [16].  From 
Figure  36,  it  can  be  seen  that  for  p  <  0.38,  q  ^  1  for  all  traffic  under  load  conditions.  This 
value  is  similar  to  the  p  value  obtained  under  the  no-load  condition  in  [5],  From  Figure 
37,  it  would  require  q  =  12  to  accommodate  the  combined  Socks  and  SNMP  traffic  (inter¬ 
arrival  time)  when  managing  2500  NEs.  Comparing  these  results  to  [5],  the  queue  size 
required  when  the  SONET  network  is  loaded  is  approximately  ten  times  less  than  when 
there  is  no  traffic  in  the  SONET  network. 
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Queue  Depth  Requirements  for  Self-similar  Traffic 


—  Socks  Traffic  (Inter-arrival  Time)  H=0.8Q73 

—  Sock  Traffic  (Packet  Size)  H=0.8256 

i  j  j  | 

r  /  ll 

~1  ! 

f 

i 

SNMP  Traffic  (inter-arrival  time)  H=0.8314 
SNMP  Traffic  (Packet  Size)  H=0.7349 

Socks  &  SNMP  Traffic  (Inter-arrival  Time) 
H=0.8124 

—  Socks  &  SNMP  Traffic  (Packet  Size) 
H=0.8248 

—  -  -  Ethernet  Traffic  (Inter-arrival  Time)  H=0.7334 

—  Ethernet  Traffic  (Packet  Size)  H=0.843 

■  /  ,7 

I 

i 

i 

i 

1  j  jj 

1 

l  1 

_ /. _ _ _ 

. ; . 

/ 

hi 

/ 

/ 

. f 

li  ! 

/  j 

/■? . 

/  / 

jfl 

7 

/ 

:// 

// 

_ _ . 

i 

i 

\ i 

i 

i  i 

i 

0.2 


0.3 


0.4 


0.5  0.6 

Utilization  p 


0.7 


0.8 


0.9 


Figure  36.  Plot  of  utilization,  p  versus  queue  depth,  q  (scale  to  <7=10) 
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Figure  37.  Plot  of  utilization,  p  versus  queue  depth,  q  (scale  to  q  =  100) 
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Figure  38.  Plot  of  utilization,  p  versus  queue  depth,  q  (scale  to  q  =  1000) 


The  maximum  number  of  NEs  required  to  obtain  utilization  of  0.38  are  then  tabu¬ 
lated  in  Table  13.  Table  13  also  presents  the  results  extracted  from  [5]  for  comparison.  It 
can  be  seen  that  CTM  4.6  can  manage  a  higher  number  of  NEs  under  load  conditions 
than  under  the  no-load  conditions.  This  is  possible  since  less  management  data  is  ex¬ 
changed  as  shown  in  Table  4.  It  is  also  observed  that  Ethernet  traffic  has  no  impact  to  the 
network.  In  addition,  from  Table  13,  q  will  be  reduced  to  1  if  only  1552  NEs  are  man¬ 
aged  instead  (compared  to  1027  NEs  under  the  no-load  condition  in  [5]).  Thus,  depend¬ 
ing  on  the  available  buffer  size,  it  is  possible  for  CTM  4.6  to  manage  2500  NEs  as  stated 
in  the  specifications  but  it  is  still  not  advisable. 
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Type  of  Traffic 

Maximum  Number  of  NEs 

Under  Load  Conditions 

Under  No-load  Conditions  (From 
Ref.  [5].) 

Socks 

1739 

1142 

SNMP 

14843 

9620 

Socks  &  SNMP 

1552 

1027 

Ethernet 

487648 

360000 

Table  13.  Maximum  number  of  NEs  required  to  obtain  a  utilization  of  0.38 


D.  SUMMARY 

Data  captured  were  analyzed  using  statistical  tools  and  self- similarity  concepts. 
The  results  obtained  were  discussed  and  compared  to  the  results  in  [5],  In  particular,  the 
difference  in  time  interval,  packet  length  and  link  utilization  of  the  management  data 
were  evaluated.  The  detailed  analysis  demonstrated  that  less  management  data  was  ex¬ 
changed  when  the  SONET  network  was  fully  loaded.  In  addition,  it  is  recommended  that 
CTM  4.6  be  used  to  manage  not  more  than  1552  NEs  for  safe  operation. 

The  following  chapter  summarizes  and  concludes  the  study.  In  addition,  more  ar¬ 
eas  that  have  not  been  explored  due  to  lack  of  resources  and  time  will  be  discussed. 


46 


VI.  CONCLUSION  AND  FURTHER  RESEARCH  AREAS 


A.  CHAPTER  OVERVIEW 

The  chapter  summarizes  and  concludes  the  research  in  this  study.  Related  re¬ 
search  areas  are  also  proposed  for  possible  extension  to  the  current  study. 


B.  CONCLUSION 

A  SONET  network  was  set  up  in  the  Advanced  Network  Laboratory.  To  study 
the  effect  of  the  traffic  loading  in  the  SONET  network  on  the  CTM  4.6,  Avalanche 
Smartbits,  a  traffic  generator,  was  installed  and  configured.  Data  was  then  passively  cap¬ 
tured  from  the  CTM  4.6  server  machine  via  Ethereal,  a  packet  sniffer.  For  the  relevance 
of  the  study,  only  Socks,  SNMPv2  and  TCP  traffic  from  CTM  4.6  were  extracted  and 
analyzed. 

The  results  gathered  from  Ethereal  were  compared  to  the  findings  obtained  in  [5], 
Preliminary  observations  showed  that  less  traffic  was  exchanged  between  the  CTM  and 
the  managed  NEs  when  the  SONET  network  is  loaded.  Close  inspection  revealed  that 
more  Socks  and  SNMP  traffic  were  transferred  when  there  is  no  user  traffic  on  the  net¬ 
work. 

Further  analysis  on  the  inter-arrival  time  and  packet  size  distribution  were  per¬ 
formed.  From  the  inter-arrival  distribution,  all  the  traffic  (Socks,  SNMPv2  and  Ethernet 
traffic)  demonstrated  long  range  dependence  and  self- similarity,  regardless  of  the  load 
conditions  in  the  SONET  network.  However,  it  was  observed  that  management  data  was 
exchanged  at  a  shorter  time  interval  without  user  traffic  in  the  SONET  network.  For  the 
packet  size  distribution,  it  was  found  that  the  packet  size  of  all  traffic  were  almost  similar- 
under  different  load  conditions. 

The  Hurst  parameter  was  then  used  to  estimate  the  self- similarity  of  all  the  traffic. 
Using  the  Variance-Index  Plot  approach,  large  values  of  H  were  found  for  all  the  traffic, 
thus  indicating  that  the  traffic  is  self-similar  and  bursty  in  nature.  These  results  were 
similar-  to  [5]  except  for  Socks  and  combined  Socks  and  SNMP  traffic. 
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Link  utilization  was  derived  for  all  the  traffic,  hi  particular,  CTM  4.6’s  Socks  and 
SNMP  traffic  had  a  link  utilization  of  0.612  when  CTM  4.6  was  used  to  manage  2500 
NEs.  This  value  was  much  lower  compared  to  the  high  utilization  of  0.926  obtained  in 
[5]  under  the  no-load  condition  in  the  SONET  network.  Though  the  utilization  was  lower 
in  the  case  of  having  user  traffic  in  the  network,  the  high  Hurst  parameter  value  computed 
may  pose  a  problem  for  the  CTM  4.6  while  managing  2500  NEs. 

A  network  utilization  versus  queue  depth  graph  was  plotted  to  determine  the 
number  of  NEs  the  CTM  could  realistically  manage,  taking  into  account  the  burstiness  of 
the  traffic.  From  the  plot,  it  is  recommended  that  the  CTM  4.6  manages  up  to  a  maxi¬ 
mum  of  1552  NEs,  operating  within  a  utilization  of  0.38  under  load  conditions  in  the 
SONET  network  to  prevent  queuing  buffer  overflow  (compared  to  1027  NEs  under  the 
no-load  condition  in  the  SONET  network). 

In  conclusion,  the  objectives  of  this  study  were  met.  It  is  hoped  that  the  results 
obtained  would  aid  service  providers  in  planning  and  managing  SONET  networks. 


C.  FURTHER  RESEARCH  AREAS 

Due  to  the  lack  of  required  resources  or  time,  a  number  of  areas  were  not  exam¬ 
ined  and  are  discussed  in  the  following  paragraphs. 

1.  Investigating  the  Effects  with  Failure  in  the  SONET  Network 
In  this  study,  management  data  were  captured  between  the  CTM  4.6  and  the  four 
managed  NEs.  The  NEs  in  this  case  are  always  up  and  working  properly.  This,  however, 
is  an  ideal  situation.  More  management  data  may  be  exchanged  in  the  event  of  a  failure 
in  one  or  more  NEs.  Due  to  the  time  constraints,  it  was  not  possible  to  shut  down  the 
NEs  randomly  so  as  to  capture  the  traffic  for  verification.  A  study  can  be  done  to  inves¬ 
tigate  the  effects  of  failures  in  the  SONET  network  on  the  management  tools. 
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2.  Investigating  the  Traffic  on  SDCC 

In  this  study,  the  traffic  coming  off  the  SDCC  was  captured  from  the  Ethernet 
network.  Although  anecdotal  observations  suggest  that  the  data  captured  on  the  Ethernet 
network  sufficiently  represents  the  traffic  on  the  SDCC,  extra  overhead  may  be  incurred 
by  the  transiting  SONET  switches  across  the  IP  network.  This  may  affect  the  accuracy  of 
the  analysis.  Due  to  the  faulty  equipment  for  capturing  the  traffic  on  SDCC,  this  area 
was  not  explored. 

3.  Use  of  Other  Vendors’  EMS 

Beside  the  CISCO’S  CTM  4.6,  there  are  other  third-party  EMSs  available  in  the 
commercial  market  (e.g.,  InCharge  from  Smarts  [23],  or  Navis  from  a  joint  partnership 
between  Lucent  and  Micromuse  [24]).  A  preliminary  evaluation  was  conducted  to  de¬ 
termine  the  interoperability  of  the  CISCO  ONS  15454s  with  the  other  EMSs.  It  was 
found  that  the  InCharge  from  Smarts  is  a  possible  alternative  to  CTM  4.6.  However,  due 
to  limited  financial  resources,  the  EMS  was  not  purchased.  It  would  be  interesting  to 
compare  the  performance  of  the  third’s  party  EMS  against  the  CISCO  CTM  4.6. 
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